From ed53f195680370b92297c6ea8181023f99d467a5 Mon Sep 17 00:00:00 2001 From: Keir Fraser Date: Wed, 12 Aug 2009 14:06:01 +0100 Subject: [PATCH] x86 svm: Fix checked builds of Windows running on AMD SVM Checked builds of Windows will, after every modification of the TPR, read it back again and assert that the value read back matches with the value written, including the priority sub-class. Make sure that we correctly preserve it on vmexit. As far as I can tell from reading the documentation, the sub-class doesn't actually do anything, so this should be pretty harmless. Signed-off-by: Steven Smith --- xen/arch/x86/hvm/svm/svm.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 6236ead0be..7c9aaadb0b 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1306,9 +1306,12 @@ asmlinkage void svm_vmexit_handler(struct cpu_user_regs *regs) * Before doing anything else, we need to sync up the VLAPIC's TPR with * SVM's vTPR. It's OK if the guest doesn't touch CR8 (e.g. 32-bit Windows) * because we update the vTPR on MMIO writes to the TPR. + * NB. We need to preserve the low bits of the TPR to make checked builds + * of Windows work, even though they don't actually do anything. */ vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI, - (vmcb->vintr.fields.tpr & 0x0F) << 4); + ((vmcb->vintr.fields.tpr & 0x0F) << 4) | + (vlapic_get_reg(APIC_TASKPRI) & 0x0F)); exit_reason = vmcb->exitcode; -- 2.30.2